home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hottest 6
/
Hottest 6 (1996)(PDSoft)[!].iso
/
pdsoft
/
demo_library
/
4427.lha
/
DamageWolf3DV1.lha
/
Wolf3d-info.txt
< prev
next >
Wrap
Text File
|
1980-01-01
|
12KB
|
293 lines
Wolf3D - Amiga
Codex: STL/Damage(SF)
C2P combination of c2p_020_fastram and c2p4.a
Gfx: STL
Quality Assurance and High Depressing: Friends :)
V1.0 16..17.12.94, (pre)^n release and obsolete as well as V1.1.
V1.1 followed some days later as a quick re-release after improvements.
Changes after V1.1:
· Game engine optimized and lots of shit kicked out from the ray routines.
· Document mistakes corrected.
V1.2 release date 26.12.94. Changes after V1.2:
· Doors (basically pretty ready, but yet disabled for unsubdividional reasons)
· Real dithering (or actually not, but should fool you :)
· EHB/OCS and 256/AGA colour modes.
· The usage of blitter added to the C2P routine.
· Faster, optimized etc...
V1.3 released? Dunno... :)
· Anyway, even more optimizations, HD crashes (not caused by the Wolf though :)
and other nice surprises (My HD's PSU blew up... Sigh)...
V1.4 release: this hopefully also spread...
V1.5 release 15.5.95 (the magic three 5s)
· Floor/Ceiling texture mapping
· Bigger screen
V1.6_BUG_kill-1 - release V1.6.1
· Looks better due to the increased amount of decimals (my fault at V1.5)
· Faster (At least 8x192x48 cycles on the bigger screen per screen calc)
· Even more faster (floor routine optimized)
· Ray tracing faster (Speedy speed the third time!)
· The bug that crashed V1.5 is now removed.
· Corrected a perspective bug.
· Sprite fading added.
· AGA and OCS modes now included in the same file! Switch with F10.
The reason for the arrival of the V1.6 is the fact that V1.5 tend to crash when
the demo compiled the first screen. The crash was an immediate screen going
foom and system halt, crash and guru when the precalculating had finished. It
was caused by the fact that AmigaDOS doesn't clear bss areas before running the
demo. Since assembler does this, I never received any problems. The
unclearance of bss caused uninitialized data areas, and the thing that crashed
it all was a tiny little word of memory, that stated the amount of tasks the
blitter had left to do. This particular little word inherited the value the
last task had left at that particular point in memory. Even a value of 64 (can
be from zero to 65536) is high enough to make the blitter run through most of
the chip memory, messing everything on its path. This counts interrupt
pointers, exec pointer and exec.library for the system, and graphics for the
engine.
One of the Murphy's laws is that the bugs never appear before the release date!
Then to the other type of fatal crash bug that has been reported to me. It may
currently occur on 68020++, and I have been told that disabling the duplication
of the zero page to the fast memory made the demo work. Could simply boil down
to the 1st bug too, as this changes the memory assignment a little. The person
telling me this assumed exeption/interrupt register setup failure. The upshot
for copying the zero page is that fast memory is faster to access and thus it
boosts up AmigaDOS little. Since this is MMU-only feature, it doesn't cross
the paths of anyone else. And some MMU people can annoy themselves with
Enforcer hits, too. Anyway, I once read a document about MMUs and zero pages,
and I don't remember any mentions about crash possibilities. Try this anyway,
if everything else fails. This is an UnCertain Area for me, could anybody help
me out? :)
I have been told that the AGA looks insanely identical to the OCS version.
That is, they are actually VERY identical. The only difference between OCS and
AGA is the amount of colours and an improved palette (256 colours - 24 bit)!
To the question of creating a game, I am open for game contracts :) .. I'm
already coding a game, though. Real mem loss anyway. About 500kB of mem will
be needed for the graphics if a game will be done, having three enemies and
nice design, just like in the official PC game Wolfenstein 3D.
Now to the almost intact original V1.5 Info text...
MAIL: andezl@kastelli.otol.fi
IRC: Check out STL!andezl@* on #amiga or #amigascne
This demo is made for an interest in coding a FAST similar 3D routine that is
used in Wolfenstein (or why not better while on it :) For a long time, that was
not possible due to the lack of algorithms required to the rendering of a 3D
screen from a simple 2D map. The last kick needed came from the documents
written by Brian Marshall.
Without him, this demo would not exist. Also extra thanks to Count Zero for
supplying me with those documents. And most thanks to Peter McGavin for his
fine Chunky sources.
The hardware requirements are kept to minimum in order to make this accessible
for everyone. The only limit is the EHB mode, which (as I recall) limits out
the A1000 machines, which don't have it.
Features:
· Two screen sizes, 128x96 and 192x160.
· Two colour modes, 64_EHB-OCS and 256-AGA.
· Floor, ceiling and wall Texture mapping.
· Depth cueing with realtime texture dithering.
· Sprites.
***
Here are the keyboard controls for the game. Mitsumis are welcome and others
are not. A1200 is especially unstabile. Key detection fails, key releases may
be left undetected, matrix fails and other general shit. Well, not fatal
though. Most of the time it works (= at least 50% of cases).
Strange though. There are no dbf wait loops, but a vblank line -loop to ensure
that enough time gets waited (read: wasted). It seems that the actual
keyboard of A1200 and some other keyboard types can't detect all the
combinations of multiple key strokes. Most of the A500's keyboards (That is
Mitsumi, I suppose) have the n-key rollover, which means that you haven't got
enough fingers to mess up the matrix. It seems very easy on the 1200 though.
Annoying.
If anybody knows a proper, errorproof way to hardware read keyboards on
non-Mitsumis with simultaneous keypresses available, please tell me. That
would help lots of people.
It seems that some of those qualifier keys are errorproof. Nice thing, but not
too helpful.
ESC/LMB=quit
Joystick Fire/R-ALT=fire current weapon. N/A
R-Amiga=modify turn left/right keys to do sidewalk. N/A
Space=open door. N/A
Shift=running mode, also available on numeric.
Numeric keyboard controls:
[ ] / *
sidewalk left move forwards sidewalk right
7 8 9 -
turn left move forwards turn right
4 5 6 +
turn left move backwards turn right fire weapon N/A
1 2 3 E
turn left move backwards turn right open doors N/A
0 .
running mode
Another method for primary controlling, although more limited, is to use arrow
keys. This helps with the A1200's keyboard. Even more helpful is to leave the
whole keyboard intact and grab a joystick instead.
The Engine
----------
What's new?
The view is completely texture mapped, in contrary to the V1.4 version that had
only the walls texture mapped. Now mapping includes walls, floors, ceilings,
sprites and doors (that are faked yet!). All the walls, ceilings and floors
are faded and dithered according the depth and the type of the texture block
(floor is the darkest, ceiling little lighter and wall receives the maximum
light) to accomplish the view perfection to the eye.
The floor/ceiling routine was started from scratch and has reached the current
form after 12 hours of optimizing/developing. This routine is the thirth one I
have made for such purpose. It is at least the fastest I have seen anywhere so
far. Sorry for not having an actual floor/ceiling texture selection map. Will
be done some day.
Here's a little comparision that I have made to the leading Wolf Clone (in my
opinion), that is yet very similar to my own: Nearest match is POOM, and I
talk about the version demonstarted in Parallax's demo Drool This.
What makes DamageWolf better than POOM?
- Soft fading, lots of entirely differing colours and only 64 colours used
(AGA uses full 256 colour palette, of course).
- Ceiling and floor are independent in both the lighting level and texture.
Any texture could be selected, but this is yet limited. (I think POOM
mirrors ceiling to floor (or the other way), fast and simple solution)
- Smaller memory usage (this means worse textures, though)
- Texture Dithering (gives more than 120 rastered colours)
- Very long distance view (one ray is traced at least 40 squares of map before
it is assumed never to hit anything), I believe the farthest on Amiga.
- Faster/Equal speed (Actually I don't know, Drool This run on 68030/50
without any framerate information except the one given by analog measuring
equipment, ie. my eyes and the size of the view wasn't mentioned (or I
didn't catch it))
What DMGWolf misses compared to POOM?
- Doors (although POOM's doors can be easily managed)
- Nice textures, animation, 128x128 blocks etc... (I am NOT a GFXian.)
- POOM has larger screen.
Of course I have seen some other Wolfs, too, but they hardly match with mine's.
I'm waiting for TextDemo5, which should have all kinds of neat stuff, and I
want to see Alien Breed 3D as well... And of course the next release of POOM
:)
I have been told that there are even more good Wolf clones, some even having 2
player playing possibilities, split screen, modem support.. Due to the lack of
AGA and 68020 (and modem), they render their unexsistence to me. Actually all
of them would :( .. I wonder if anyone else continues supporting the A500?
General info
------------
This Wolfenstein uses ray firing and nothing else to draw the view. The ray
firing is specially optimized to be able to trace all the mindbursting
distances there are in very fast manner. However, rayfiring means that the
walls have to be at 90° degrees with each other. Any texture can be selected
for wall blocks, and the wall blocks can be transparent. There is currently
only one light source (or actually no light sources at all, but general fading
from the player), and I think it will remain this way.
The AGA usage has improved. Last time there was 256 colours. Now there is
also an 24bit palette, which means much nicer fading. Anyway, it is pretty
hard to support AGA without being able to test the routine at all.
I noticed a flaw in the blitter buffering, and I corrected it. Last time the
C2P left the previous screen unsecured for a little while - about 33% of a
frame, which could have malfunctioned on somebody's 68060 :) I can guess that
this wasn't actually very significant improvement :) .. C2P now sorts
everything out perfectly.
The door sprites are removed, as the routine can't support them anymore due to
MAJOR changes in the screen drawing algortihm tabling sequences. The doors can
still be added, of course. Perhaps I will create the real textured doors next.
And the last note is that the Texture Dithering process has bugs. This appears
as sudden hiliting of some colours/dithering componenets. Don't know what
causes this. Anyway, all this little finishnessless is due to the fact that I
haven't yet cared about them too much. Well, there will be re-releases in case
this version turns out to have more bugs than advantages :)
The graphics may change to real AGA ones for next release after/during summer.
B.B: it is up to you :)
I access Internet via my school, and from now on I have to use other means.
The result is that I can visit to read my mailbox pretty rarely. So don't
wonder if my responses take time.
***
Enough. N-joy, have fun, explore. Hope it works this time little better. If
you have comments, suggestions or questions, just mail me. Any mail would be
most welcome.
* STL / Damage --- Antti Lankila --- andezl@kastelli.otol.fi *
* ^^^ = IRC - - MAIL *